-
Notifications
You must be signed in to change notification settings - Fork 17.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AP_Motors: Heli: Single: rework tail rotor handling #25603
Conversation
Are you thinking of this as a starting PR and doing more later as incremental changes? The reason I ask is because IMHO it would be nice if we moved tail into it's own class much like RSC and swashplate. If we used a backend and front end style we could sperate out the different tail types quite cleanly. This way we could handle the params for the different tail types separately with enables (i think we have 1 level of params left which would be enough to do this>) We could also move all of the switch case statements out of Heli_Single and into "TailRotor.cpp". In any case, I like this rework, as it can just be a stepping stone to what I mentioned above, if others feel there is value in that? |
I started off doing a class, however its not as clean as the swash stuff. Firstly because its only used for single heli there is no duplicated code. Secondly it uses params and values from motors so we would have to add hooks to get the data we need. On the whole I think the bigger re-work will cost a bunch of flash and have little benefit. Especially if we have to move around params. However there are certainly tidy ups that could follow this PR. |
This actually could be useful because we have other single main rotor styles that could become separate heli frames and take on their own class. We have the pulse motor which could be its own frame and I have always been looking to put a compound heli frame which could make use of a tail type class So this may be something to consider in the future. |
I have added the ability to set the |
@IamPete1 Thanks for including COL2YAW in your tests. Did you use a non-zero value for the COL2YAW parameter? if so what was the value? |
I used 1, I figured so long as the value was not 0 any number would prove equivalence before vs after this change. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This is a none-functional change to re-work tail rotor handling into what is hopefully easier to understand. This moves the tail types to be a enum class and uses switch statements where possible.
Helper functions have been added to check if DDFP and direct drive var pitch.
Yaw offset had been moved to its own function.
As usual the motors example has been updated to allow testing of different tail types, it shows no difference before vs after.